Summary

Adds the protocol for in-dive annotations: during a dive a diver (or any connected client) taps an annotation type in the app's command palette, and the annotation is broadcast to every connected client and recorded into the dive logfile. Part of the Blueye Cloud in-dive annotations feature.

Annotations are self-contained — each one carries the type's display fields (type_name, type_icon, type_color) inline, so the drone, connected clients, and the dive logfile can render it with no separate catalogue. The app keeps the full annotation-type catalogue locally (synced from Blueye Cloud) to drive its palette; only complete annotations go over the wire. type_slug is kept so Blueye Cloud can correlate the annotation back to its type on import.

Note: an earlier revision of this PR pushed/embedded an AnnotationCatalog to the drone. That was simplified away in favour of self-contained annotations (see commit history) — it removes the catalogue-sync messages and the "push catalogue before the dive" ordering dependency.

Messages

message_formats.proto

• AnnotationSource enum — CLOUD / APP / DRONE.
• Annotation — a self-contained annotation: type_slug, type_name, type_icon, type_color, title, body, duration, source.

control.proto — app → drone (request)

• AnnotationCtrl — request to add an annotation. Fire-and-forget, like LightsCtrl.

telemetry.proto — drone → all clients (authoritative, broadcast, logged)

• AnnotationTel — the annotation that now exists on the dive. The drone echoes a client's AnnotationCtrl here to every connected client (so clients converge), can also originate one itself (source = DRONE), and writes it to the logfile.

Design notes

• Self-contained annotations — display fields are inline, so any client / the .bez / downstream tooling can render an annotation without a second lookup; a late joiner's GetTelemetryReq("AnnotationTel") returns something fully renderable. Captures point-in-time appearance, so renaming a type in Cloud later doesn't retro-mutate old dives.
• type_slug for correlation — kept so Blueye Cloud links the annotation to its AnnotationType row on import (grouping, "show all Hazards"); empty for a free-form annotation.
• Authoritative state comes up, not down — the app renders from the AnnotationTel it gets back, not from its own Ctrl, so multiple connected clients converge (client 1 adds → client 2 sees it).
• No timestamp on Annotation — the enclosing BinlogRecord carries the time, like every other logged sample.
• source is an informational provenance hint, not a security claim — intentionally not enforced (first-party, non-adversarial protocol); the app sets APP, the drone sets DRONE. See review thread replies.
• Additive & backward-compatible, no new imports.

Open question for review

AnnotationTel is a discrete event, not periodic state. This telemetry plane is built around publish/log frequency (SetPubFrequencyReq / SetLogFrequencyReq, in Hz). Please confirm the bus can publish/log it on-change, once per event — i.e. every annotation is delivered to subscribers and written to the logfile, with no rate-based sampling that could merge two quick annotations or drop one.

Validation

• protoc compiles all protos together (syntax + cross-refs resolve). ✓
• No lines > 120 chars (protolint max_line_length). ✓
• VersionPrefix intentionally not bumped — the protocol version tracks the BlueyeApp version and is bumped together with the app.

Not in this PR

• App UI (command palette, FontAwesome icon rendering — the FA7 Pro lookup is already in BlueyeApp).
• Blueye Cloud .bez parser that reconstructs annotation rows from AnnotationTel records (correlating by type_slug, falling back to the inlined display fields for free-form annotations).

🤖 Generated with Claude Code